Written by Campbell Turner
Published on: 2024-11-09
Maybe the time has come to compile your best works for your portfolio and come up empty or someone you haven’t talked to in a while asks you about a project you abandoned long ago. Either way, you’ve got a pile of unfinifhed projects and you’re tired of adding to it.
Have you ever had an idea that you thought was brilliant and instantly felt so connected to it that you made it your main project immediately? No prep, no planning, just diving in headfirst. You dreamed of how awesome it was going to be and excited told all your friends, but it never leaves idea land or , if it did, you didn’t make progress. Either way, the guilt piles up and a new shiny idea came along and the cycle continued. When working on a long term project (one that would take more than a week to complete), even if your idea is amazing, you shouldn’t commit until you’ve at least got a prototype. You’ll want to have a Game Design Document as well (Its size will vary depending on project size and genre). The purpose is to take your project out of imagination and start thinking through your idea and see what it takes. The prototype helps you figure out if your idea is fun, both to develop and to play.
Have you ever noticed that talking about your project can feel better than actually working on it? It’s been shown that talking about a goal may make you less likely to achieve it because you get a boost by talking about it, which is always way easier than getting it done. While I don’t think you have to keep quiet about your project forever, I do think you should keep track of how often you talk about your project compared to how often you work on it. It makes you more conscious of both and by tracking you can find a way to figure out what the balance is for you.
It’s every developer’s nightmare: putting their baby out into the world and everyone hating it. As developers we know what the game was when it was still in our heads and our dreams of getting a content creator we enjoy to talk about them. The exact moment you start to create your project as a real thing, you guarantee it will never be exactly as you dreamed of. This isn’t a bad thing, because in recognizing that fact you must realize that this has been true for everyone who’s created anything ever. This is because our dreams don’t have any consideration for budget, or analyze what’s worked before in our genre of choice, nor do they keep the flow of gameplay and exposition in check. There will never be a perfect game so you’re not failing as a developer by not making one.
You just really like working on this project, because of the characters, world, genre, or a mechanic you feel attached to. If you’re honest with yourself, your project has been done for a long time. Just because you’re calling a project complete doesn’t mean you can’t touch the parts of it you like in another project. Even if you don’t want to make a direct sequel, you can still use elements from your other projects. Mechanics can always be reused as can character archetypes, or worlds. There’s a limit to how much you can polish a game. While it can be difficult to put something you’re so invested in in front of an audience, there you will learn the most.
It was just going to be an “easy project”, a little “experiment” that grew legs and became much more than that. Now it’s a beast that you feel you’ll never finish. So you either make a long struggle to make a dent in your project or you abandon it, feeling like a bad developer because of it. Sometimes you’ll have to cut features, it’s never pleasant but can be a good time to reexamine the core of your game and what actually needs to be in the final version. It may feel like you’re sacrificing part of your vision, but visions are no good if they’re never realized.
You may have been expecting working on multiple projects at once or overcommitting to be in this list of reasons, but I chose not to include it because I don't believe that's the real problem. It's merely an easy cover for the problem. More often than not these projects have a problem that's covered in the rest of this article. For example, the problem isn't working *two* huge projects, the two problems are that you're working on *huge* projects.
Honestly, many developers fall into more than one of these camps and that’s ok. Recognizing why a project failed is just as (if not more) important than analyzing a successful one. Also I want to note this is not an attack nor is it a negative post. Everyone has dropped a project or two and the reason I wrote about these specific reasons is because I’ve fallen prey to each of them multiple times. Even if you’re mindful of every pitfall on this list, you may still drop a project or two. This isn’t mean you’ve failed as a perfect record isn’t the goal. What matters is having a larger percentage of finished projects than scrapped ones.